home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Apr 89 / T0018-Locking recap-Apr89 < prev    next >
Encoding:
Text File  |  1989-04-13  |  3.3 KB  |  68 lines  |  [TEXT/GEOL]
  1. Item    1174037                         13-April-89        07:57
  2.  
  3. From:   MUYSVASOVIC1                    ER&D - J-D Muys-Vasovic
  4.  
  5. To:     UK0004                          Bacchus & Smith, Paul Smith
  6.         UK0016                          Icon Technology UK
  7.         BEL0076                         Hermes Systems SA
  8.         FRIEDRICH1                      Friedrich, Steve
  9.         ROLLIN1                         Rollin, Keith A.
  10.         ALGER                           Alger, Jeff
  11.  
  12. cc:     MACAPP.TECH$                    MACAPP Tech
  13.  
  14. Sub:    Locking recap
  15.  
  16. When I recall all this thread about locking objects, it seems to me that the
  17. problem is more general: this concerns ANY handle on the heap, that's why I
  18. would like to raise the following points:
  19.  
  20. 1- Yes, locking is dangerous, especially as far as error handling is concerned.
  21. This is not related to objects or MacApp in anyway, though. Following the same
  22. idea, it is possible to contest the HLock, HUnlock OS routines. They prove
  23. necessary however, and it has always been said that they must be used
  24. cautiously and sparingly (though the main reason invoked is heap
  25. fragmentation).
  26.  
  27. 2- The counting approach seems perfect, with the possible exception that it
  28. uses 4 bytes more per relocatable block: the count MUST be 32 bits, or at least
  29. more than 16 bits! But ANY block on the heap has at least 8 bytes of overhead
  30. (the block header), and any relocatable block on the heap has at least 12 bytes
  31. of overhead (with the master pointer). That would mean a 33% increase of the
  32. overhead. I believe memory is cheap enough nowadays to allow that.
  33.  
  34. 3- I claim that the handling of the count should have been handled by the OS in
  35. the first (or second) place. The _HLock and _HUnlock traps should take care of
  36. updating the count, possibly calling SysError or Debugger when it becomes
  37. negative, of course depending on either a global (like $12D which controls the
  38. break after _LoadSeg), or better, on a field of the current zone record.
  39.  
  40. 4- This can be implemented in two ways: either store another field in the block
  41. header for handles, or better yet, store it together with the master pointer in
  42. the master pointer blocks. Why is this better? Today, a master pointer is a
  43. 4-byte record, with 24 bits address and 8 bits flags. Tomorrow, in a 32 bits
  44. OS, we will need all 32 bits for the address, and the flags will have to move
  45. elsewhere. The solution is to make the master pointer an 8-byte record. Not 6
  46. because for efficiency reasons, the address must be long-word aligned. By the
  47. way, this is already so under A/UX. This leaves 24 bits as a possible count
  48. field. Now the question is: are 24 bits (16 millions limit) enough? I don't
  49. know. I would say yes! I think a spy tool would be easy to write to check that
  50. out.
  51.  
  52. 5- Speaking of MacApp, this scheme can indeed be implemented an object field as
  53. shown earlier. And this does not mean that the restrictions discussed in 1-
  54. above don't apply any more. The scheme is just a bit safer. However I have no
  55. idea as to how an error handler (for example) could avoid poking inside the
  56. content of an object to unlock it, or more precisely, to restore the count to
  57. the value it had just before the handler was installed! In fact I have one,
  58. unusable: the lock method installs a handler, the unlock method calls
  59. success!!!
  60.  
  61.  
  62. Please comment!
  63.  
  64. Jean-Denis Muys-Vasovic
  65. Developer Services - R&D Europe
  66.  
  67.  
  68.